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Abstract 


This document describes a non-standard, but widely implemented, 
modification to TCP’s handling of ICMP soft error messages that 
rejects pending connection-requests when those error messages are 
received. This behavior reduces the likelihood of long delays 
between connection-establishment attempts that may arise in a number 
of scenarios, including one in which dual-stack nodes that have IPv6 
enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 
environments. 
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Introduction 


The handling of network failures can be separated into two different 
actions: fault isolation and fault recovery. Fault isolation 
consists of the actions that hosts and routers take to determine that 
there is a network failure. Fault recovery, on the other hand, 
consists of the actions that hosts and routers perform in an attempt 
to survive a network failure [RFC0816]. 


In the Internet architecture, the Internet Control Message Protocol 
(ICMP) [RFCO792] is one fault isolation technique to report network 
error conditions to the hosts sending datagrams over the network. 


When a host is notified of a network error, its network stack will 
attempt to continue communications, if possible, in the presence of 
the network failure. The fault recovery strategy may depend on the 
type of network failure taking place and the time at which the error 
condition is detected. 


This document analyzes the problems that may arise due to TCP’s fault 
recovery reactions to ICMP soft errors. It analyzes the problems 
that may arise when a host tries to establish a TCP connection with a 
multihomed host that has some unreachable addresses. Additionally, 
it analyzes the problems that may arise in the specific scenario 
where dual-stack nodes that have IPv6 enabled by default are deployed 
in IPv4 or mixed IPv4 and IPv6 environments. 


Finally, we document a modification to TCP’s reaction to ICMP 
messages indicating soft errors during connection startup that has 
been implemented in a variety of TCP/IP stacks to help overcome the 
problems outlined below. We stress that this modification runs 
contrary to the standard behavior and this document unambiguously 
does not change the standard reaction. 


[Gont] describes alternative approaches for dealing with the problem 
of long delays between connection-establishment attempts in TCP. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


Error Handling in TCP 


Network errors can be divided into soft and hard errors. Soft errors 
are considered to be transient network failures that are likely to be 
solved in the near term. Hard errors, on the other hand, are 
considered to reflect network error conditions that are unlikely to 
be solved in the near future. 
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The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that 
the ICMP messages that indicate soft errors are ICMP "Destination 
Unreachable" codes 0 (network unreachable), 1 (host unreachable), and 


5 (source route failed); ICMP "Time Exceeded" codes 0 (time to live 
exceeded in transit) and 1 (fragment reassembly time exceeded); and 
ICMP "Parameter Problem". Even though ICMPv6é did not exist when 


[RFC1122] was written, one could extrapolate the concept of soft 
errors to ICMPv6é "Destination Unreachable" codes 0 (no route to 
destination) and 3 (address unreachable); ICMPv6 "Time Exceeded" 
codes 0 (hop limit exceeded in transit) and 1 (fragment reassembly 
time exceeded); and ICMPv6 "Parameter Problem" codes 0 (erroneous 
header field encountered), 1 (unrecognized Next Header type 
encountered), and 2 (unrecognized IPv6 option encountered) [RFC4443]. 


Sa A NEEE jen a ae Sosa + 
| ICMP | ICMPv6 | 
E S S A A A D A E E N a E ENT E: SSE + 
| Destination Unreachable (codes | Destination Unreachable (codes | 
| 0, 1, and 5) | 0 and 3) | 
| a Soa oa oa 4+-------------------------------- + 
| Time Exceeded (codes 0 and 1) | Time Exceeded (codes 0 and 1) | 
4+---------------------------------- E + 
| Parameter Problem | Parameter Problem (codes 0, 1, | 
| | and 2) | 
foSos See eee e ose $e Bee aS Se eee ee OSS SSeS + 


Table 1: Extrapolating the concept of soft errors to ICMPv6 


When there is a network failure that is not signaled to the sending 
host, such as a gateway corrupting packets, TCP’s fault recovery 
action is to repeatedly retransmit the corresponding data until 
either they get acknowledged or the connection times out. 


In the case that a host does receive an ICMP error message referring 
to an ongoing TCP connection, the IP layer will pass this message up 
to the corresponding TCP instance to raise awareness of the network 
failure [RFC1122]. TCP’s reaction to ICMP messages will depend on 
the type of error being signaled. 


2.1. Reaction to ICMP Error Messages That Indicate Hard Errors 
When receiving an ICMP error message that indicates a hard error 
condition, compliant TCP implementations will simply abort the 
corresponding connection, regardless of the connection state. 
The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that 


TCP SHOULD abort connections when receiving ICMP error messages that 
indicate hard errors. This policy is based on the premise that, as 
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hard errors indicate network error conditions that will not change in 
the near term, it will not be possible for TCP to usefully recover 
from this type of network failure. 


It should be noted that virtually none of the current TCP 
implementations follow the advice in [RFC1122], and they do not abort 
the corresponding connection when an ICMP hard error is received for 
a connection that is in any of the synchronized states 
[ICMP-ATTACKS]. 


2.2. Reaction to ICMP Error Messages That Indicate Soft Errors 


If an ICMP error message is received that indicates a soft error, TCP 
will repeatedly retransmit the corresponding data until either they 
get acknowledged or the connection times out. In addition, the TCP 
sender may record the information for possible later use (see 
[Stevens], pp. 317-319). 


The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that 
TCP MUST NOT abort connections when receiving ICMP error messages 
that indicate soft errors. This policy is based on the premise that, 
as soft errors are transient network failures that will hopefully be 
solved in the near term, one of the retransmissions will succeed. 


When the connection timer expires and an ICMP soft error message has 
been received before the timeout, TCP can use this information to 
provide the user with a more specific error message (see [Stevens], 
pp. 317-319). 


This reaction to soft errors exploits a valuable feature of the 
Internet -- that, for many network failures, the network can be 
dynamically reconstructed without any disruption of the endpoints. 


3. Problems That May Arise from TCP’s Reaction to Soft Errors 
3.1. General Discussion 


Even though TCP’s fault recovery strategy in the presence of soft 
errors allows for TCP connections to survive transient network 
failures, there are scenarios in which this policy may cause 
undesirable effects. 


For example, consider a scenario in which an application on a local 
host is trying to communicate with a destination whose name resolves 
to several IP addresses. The application on the local host will try 
to establish a connection with the destination host, usually cycling 
through the list of IP addresses until one succeeds [RFC1123]. 
Suppose that some (but not all) of the addresses in the returned list 
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are permanently unreachable. If such a permanently unreachable 
address is the first in the list, the application will likely try to 
use it first and block waiting for a timeout before trying an 
alternate address. 


As discussed in Section 2, this unreachability condition may or may 
not be signaled to the sending host. If the local TCP is not 
signaled concerning the error condition, there is very little that 
can be done other than to repeatedly retransmit the SYN segment and 
wait for the existing timeout mechanism in TCP, or an application 
timeout, to be triggered. However, even if unreachability is 
signaled by some intermediate router to the local TCP by means of an 
ICMP soft error message, the local TCP will still repeatedly 
retransmit the SYN segment until the connection timer expires (in the 
hopes that the error is transient). The Host Requirements RFC 
[RFC1122] states that this timer MUST be large enough to provide 
retransmission of the SYN segment for at least 3 minutes. This would 
mean that the application on the local host would spend several 
minutes for each unreachable address with which it tries to establish 
the TCP connection. These long delays between connection- 
establishment attempts would be inappropriate for many interactive 


applications, such as the Web. [Shneiderman] and [Thadani] offer some 
insight into interactive systems (e.g., how the response time affects 
the usability of an application). This highlights that there is no 


one definition of a "transient error" and that the level of 
persistence in the face of failure represents a tradeoff. 


It is worth noting that while most applications try the addresses 
returned by the name-to-address function in serial, this is certainly 
not the only possible approach. For example, applications could try 
multiple addresses in parallel until one succeeds, possibly avoiding 
the problem of long delays between connection-establishment attempts 
described in this document [Gont]. 


3.2. Problems That May Arise with Dual-Stack IPv6 on by Default 


A particular scenario in which the above type of problem may occur 
regularly is that where dual-stack nodes that have IPv6 enabled by 
default are deployed in IPv4 or mixed IPv4 and IPv6 environments and 
the IPv6 connectivity is non-existent [RFC4943]. 


As discussed in [RFC4943], there are two possible variants of this 


scenario, which differ in whether or not the lack of connectivity is 
signaled to the sending node. 
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In those scenarios in which packets sent to a destination are 
silently dropped and no ICMPv6 [RFC4443] errors are generated, there 
is little that can be done other than to wait for the existing 
connection-timeout mechanism in TCP, or an application timeout, to be 
triggered. 


In scenarios where a legacy node has no default routers and Neighbor 
Unreachability Detection (NUD) [RFC4861] fails for destinations 
assumed to be on-link, or where firewalls or other systems that 
enforce scope boundaries send ICMPv6 errors, the sending node will be 
signaled of the unreachability problem. However, as discussed in 
Section 2.2, compliant TCP implementations will not abort connections 
when receiving ICMP error messages that indicate soft errors. 


4. Deployed Workarounds for Long Delays between Connection- 
Establishment Attempts 


The following subsections describe a number of workarounds for the 
problem of long delays between connection-establishment attempts that 
have been implemented in a variety of TCP/IP stacks. We note that 
treating soft errors as hard errors during connection establishment, 
while widespread, is not part of standard TCP behavior and this 
document does not change that state of affairs. The consensus of the 
TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to 
document this widespread implementation of nonstandard TCP behavior 
but to not change the TCP standard. 


4.1. Context-Sensitive ICMP/TCP Interaction 


As discussed in Section 1, it may make sense for the fault recovery 
action to depend not only on the type of error being reported but 
also on the state of the connection against which the error is 
reported. For example, one could infer that when an error arrives in 
response to opening a new connection, it is probably caused by 
opening the connection improperly, rather than by a transient network 
failure [RFC0816]. 


A number of TCP implementations have modified their reaction to all 
ICMP soft errors and treat them as hard errors when they are received 
for connections in the SYN-SENT or SYN-RECEIVED states. For example, 
this workaround has been implemented in the Linux kernel since 
version 2.0.0 (released in 1996) [Linux]. However, it should be 
noted that this change violates section 4.2.3.9 of [RFC1122], which 
states that these ICMP error messages indicate soft error conditions 
and that, therefore, TCP MUST NOT abort the corresponding connection. 
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[RFC3168] states that a host that receives a RST in response to the 
transmission of an ECN (Explicit Congestion Notification)-setup SYN 
packet MAY resend a SYN with the CWR (Congestion Window Reduced) and 
ECE (ECN-Echo) bits cleared. This is meant to deal with faulty 
middle-boxes that reject connections when a SYN segment has the ECE 
and CWR bits set. Some faulty middle-boxes (e.g., firewalls) may 
reject these connection requests with an ICMP soft error of type 3 
(Destination Unreachable), code 0 (net unreachable) or 1 (host 
unreachable), instead of a RST. Therefore, a system that processes 
ICMP soft error messages as hard errors when they are received for a 
connection in any of the non-synchronized states could resend the SYN 
segment with the ECE and CWR bits cleared when an ICMP "net 
unreachable" (type 3, code 0) or "host unreachable" (type 3, code 1) 
error message is received in response to a SYN segment that had these 
bits set. 


Section 4.2 discusses a more conservative approach than that sketched 
above, which is implemented in FreeBSD. 


4.2. Context-Sensitive ICMP/TCP Interaction with Repeated Confirmation 


A more conservative approach than simply treating soft errors as hard 
errors (as described above) would be to abort a connection in the 
SYN-SENT or SYN-RECEIVED states only after an ICMP soft error has 
been received a specified number of times and the SYN segment has 
been retransmitted more than some specified number of times. 


Two new parameters would have to be introduced to TCP, to be used 
only during the connection-establishment phase: MAXSYNREXMIT and 
MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN 
segment would have to be retransmitted before a connection is 
aborted. MAXSOFTERROR would specify the number of ICMP messages 
indicating soft errors that would have to be received before a 
connection is aborted. 


Two additional state variables would need to be introduced to store 
additional state information during the connection-establishment 
phase: "nsynrexmit" and "nsofterror". Both would be initialized to 
zero when a connection attempt is initiated, with "nsynrexmit" being 
incremented by one every time the SYN segment is retransmitted and 
"nsofterror" being incremented by one every time an ICMP message that 
indicates a soft error is received. 


A connection in the SYN-SENT or SYN-RECEIVED states would be aborted 


if "nsynrexmit" was greater than MAXSYNREXMIT and "nsofterror" was 
simultaneously greater than MAXSOFTERROR. 
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This approach would give the network more time to solve the 
connectivity problem than does simply aborting a connection attempt 
upon reception of the first soft error. However, it should be noted 
that, depending on the values chosen for the MAXSYNREXMIT and 
MAXSOFTERROR parameters, this approach could still lead to long 
delays between connection-establishment attempts, thus not solving 
the problem. For example, BSD systems abort connections in the SYN- 
SENT or the SYN-RECEIVED state when a second ICMP error is received 
and the SYN segment has been retransmitted more than three times. 
They also set up a "connection-establishment timer" that imposes an 
upper limit on the time the connection-establishment attempt has to 
succeed, which expires after 75 seconds (see [Stevens2], pp. 828- 
829). Even when this policy may be better than the three-minute 
timeout policy specified in [RFC1122], it may still be inappropriate 
for handling the potential problems described in this document. This 
more conservative approach has been implemented in BSD systems for 
more than ten years [Stevens2]. 


We also note that the approach given in this section is a generalized 
version of the approach sketched in the previous section. In 
particular, with MAXSOFTERROR set to 1 and MAXSYNREXMIT set to zero, 
the schemes are identical. 


5. Possible Drawbacks of Changing ICMP Semantics 


The following subsections discuss some possible drawbacks that could 
arise from use of the non-standard modifications to TCP’s reaction to 
soft errors, which are described in Section 4.1 and Section 4.2. 


5.1. Non-Deterministic Transient Network Failures 


In scenarios where a transient network failure affects all of the 
addresses returned by the name-to-address translation function, all 
destinations could be unreachable for some short period of time. For 
example, a mobile system consisting of a cell and a repeater may pass 
through a tunnel, leading to a loss of connectivity at the repeater, 
with the repeater sending ICMP soft errors back to the cell. Also, a 
transient routing problem might lead some intervening router to drop 
a SYN segment that was meaning to establish a TCP connection and send 
an ICMP soft error back to the host. Finally, a SYN segment carrying 
data might get fragmented and some of the resulting fragments might 
get lost, with the destination host timing out the reassembly process 
and sending an ICMP soft error back to the sending host (although 
this particular scenario is unlikely because, while [RFC0793] allows 
SYN segments to carry data, in practice they do not). In such 
scenarios, the application could quickly cycle through all the IP 
addresses in the list and return an error, when it could have let TCP 
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5 


5; 


retry a destination a few seconds later, when the transient problem 
could have disappeared. In this case, the modifications described 
here make TCP less robust than a standards-compliant implementation. 


Additionally, in many cases a domain name maps to a single IP 
address. In such a case, it might be better to try that address 
persistently according to normal TCP rules, instead of just aborting 
the pending connection upon receipt of an ICMP soft error. 


-2. Deterministic Transient Network Failures 


There are some scenarios in which transient network failures could be 
deterministic. For example, consider a scenario in which upstream 
network connectivity is triggered by network use. That is, network 
connectivity is instantiated only on an "as needed" basis. In this 
scenario, the connection triggering the upstream connectivity could 
deterministically receive ICMP Destination Unreachables while the 
upstream connectivity is being activated, and thus would be aborted. 
Again, in this case, the modifications described here make TCP less 
robust than a standards-compliant implementation. 


3. Non-Compliant Network Address Translators (NATs) 


Some NATs respond to an unsolicited inbound SYN segment with an ICMP 
soft error message. If the system sending the unsolicited SYN 
segment implements the workaround described in this document, it will 
abort the connection upon receipt of the ICMP error message, thus 
probably preventing TCP’s simultaneous open from succeeding through 
the NAT. However, it must be stressed that those NATs described in 
this section are not BEHAVE-compliant and therefore should implement 
REQ-4 of [RFC5382] instead. 


In those scenarios in which such a non-BEHAVE-compliant NAT is 
deployed, TCP simultaneous opens could fail. While undesirable, this 
is tolerable in many situations. For instance, a number of host 
implementations of TCP do not support TCP simultaneous opens 
[Zuquete]. 


Security Considerations 


This document describes a non-standard modification to TCP’s reaction 
to soft errors that has been implemented in a variety of TCP 
implementations. This modification makes TCP abort a connection in 
the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP 
error message that indicates a soft error. Therefore, the 
modification could be exploited to reset valid connections during the 
connection-establishment phase. 
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The non-standard workaround described in this document makes TCP more 
vulnerable to attack, even if only slightly. However, we note that 
an attacker wishing to reset ongoing TCP connections could send any 
of the ICMP hard error messages in any connection state. 


Generally, TCP backs off its retransmission timer each time it 
retransmits the SYN segment for the same connection. If a TCP 
implements the modification described in this document, that is, 
tries the next address in the list upon receipt of an ICMP error 
message, it might end up injecting more packets into the network than 
if it had simply retried the same address a number of times. 
However, compliant TCP implementations might already incur this 
behavior (e.g., as a result of cycling through the list of IP 
addresses in response to RST segments) as there are currently no 
recommendations on methods for limiting the rate at which SYN 
segments are sent for connecting to a specific destination. 


A discussion of the use of ICMP to perform a variety of attacks 
against TCP, and a number of counter-measures that minimize the 
impact of these attacks, can be found in [ICMP-ATTACKS]. 


A discussion of the security issues arising from the use of ICMPv6 
can be found in [RFC4443]. 
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